Systems and methods for processing global financial transactions

ABSTRACT

A computer implemented method performed by a global transaction processing system includes receiving a transaction request from an originator, the transaction request includes transactional data. The method includes validating the transactional data to determine one or more parameters associated with the requested transaction. The method includes dynamically generating a transaction information request form, the transaction request form including one or more requests for specific transactional data from the originator based on the one or more parameters associated with the requested transaction. The method includes transmitting the transaction information form to the originator and receiving the requested specific transactional data from the originator. The method also includes validating the transaction request based on the received transaction request and the received specific transactional data to determine if the transaction request is valid, as well as processing the transactional request based on the transaction request being determined to be a valid transaction request.

BACKGROUND

With the rise of globalization, the number of international financialtransactions is enormous. These transactions, occurring between multipleparties in multiple countries, can be complex to process due todiffering financial requirements and regulations associated withdifferent countries. Often, this can lead to transactions failing to beprocessed, requiring the transactions to be submitted again, requiringadditional time and, potentially, fees and other costs associated withperforming the transaction. One common point of failure in internationaltransactions is a failure on the part of the originator to provide allof the information required by the receiving party. For example, certaincountries associated with the recipient may require additionalinformation not required in the originator's country of origin, and viceversa. Failure to provide this information often results in thetransaction being unable to be processed, requiring the transaction tobe performed again. However, in some instances the originator may not befully aware of why the transaction failed, and again neglect to includethe required information, resulting in yet another failure. Accordingly,it would be desirable to have systems and methods for determining whatinformation is required based on the transactions, and, in someinstances, an ability to automatically correct.

SUMMARY

According to one example embodiment, a computer implemented methodperformed by a global transaction processing system includes receiving atransaction request from an originator. The transaction request includestransactional data, which can include originator account information,originator identification information, a transaction amount, atransaction recipient, and/or transaction recipient account information.The method further includes validating the transactional data todetermine one or more parameters associated with the requestedtransaction. The method also includes dynamically generating atransaction information request form, the transaction request formincluding one or more requests for specific transactional data from theoriginator based on the one or more parameters associated with therequested transaction. The method further includes transmitting thetransaction information form to the originator and receiving therequested specific transactional data from the originator. The methodalso includes validating the transaction request based on the requestedtransaction request and the received specific transactional data todetermine if the transaction request is valid, as well as processing thetransactional request based on the transaction request being determinedto be a valid transaction request. Processing the transactional requestincludes generating one or more data messages containing thetransactional data and the requested specific transactional data. Thedata messages are configured to be readable by a receiving FI associatedwith the transaction recipient.

According to another example embodiment a system for processing globaltransaction includes an originating financial institution computingsystem. The originating financial institution computing system isconfigured to receive a global transaction request, the transactionrequest including transactional data. The transactional data includesoriginator account information, originator identification information, atransaction amount, a transaction recipient, and transaction recipientaccount information. The originating financial institution computingsystem is further configured to validate the transactional data todetermine one or more parameters associated with the global transactionrequest and dynamically generate a transaction information request form.The transaction information request form including one or more requestsfor specific transactional data from the originator based on the one ormore parameters associated with the global transaction request. Theoriginating financial institution computing circuit further configuredto validate the transaction request based on the received globaltransaction request and the requested specific transactional data todetermine if the global transaction request is valid. The originatingfinancial institution computing system additionally configured toprocess the transactional request based on the global transactionrequest being determined to be a valid transaction request. Processingthe transactional request comprises generating one or more data messagescontaining the transactional data and the requested specifictransactional data, the data messages configured to be readable by areceiving FI associated with the transaction recipient. The originatingfinancial institution computing system further configured to transmitthe processed transactional request to the recipient FI computingcircuit.

According to another example embodiment a global transaction processingsystem includes an originating financial institution computing system.The originating financial institution computing system is configured toreceive a global transaction request from a user device, the transactionrequest including transactional data. The originating financialinstitution computing system is further configured to validate thetransactional data to determine one or more parameters associated withthe global transaction request and dynamically generate a transactioninformation request form. The transaction information request formincluding one or more requests for specific transactional data from theoriginator based on the one or more parameters associated with theglobal transaction request. The originating financial institutioncomputing system further configured to validate the transaction requestbased on the received global transaction request and the requestedspecific transactional data to determine if the global transactionrequest is valid. The originating financial institution computing systemis additionally configured to process the transactional request based onthe global transaction request being determined to be a validtransaction request. Processing the transactional request includesgenerating one or more data messages containing the transactional dataand the requested specific transactional data. The data messages areconfigured to be readable by a receiving FI associated with thetransaction recipient. The originating financial institution computingsystem is further configured to transmit the processed transactionalrequest to the receiving FI computing system. The originating financialinstitution computing system further configured to determine if theglobal transaction request is automatically repairable based on thetransaction request being determined to be invalid, and automaticallyrepair the global transaction request based on the invalid transactionrequest being determined to be able to be automatically repairable. Theoriginating financial institution computing system also configured togenerate an error report based on the invalid global transaction requestbeing determined to be unable to be dynamically repaired, wherein thegenerated error report is transmitted to the originator.

These and other features, together with the organization and manner ofoperation thereof, will become apparent from the following detaileddescription when taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram of global transaction system, according to anembodiment.

FIG. 2 is a block diagram of an example financial transaction request,according to an embodiment.

FIG. 3 is a flow diagram of a transaction request correction process,according to various embodiments.

FIG. 4 is a flow diagram illustrating a process for processing batchtransactions, according to various embodiments.

FIG. 5 is a flow diagram illustrating an example implementation of themethod shown in FIG. 3.

FIG. 6 is a flow diagram illustrating an example implementation of themethod shown in FIG. 4.

DETAILED DESCRIPTION

Globalization has increased the amount of international transactionsthat occur every day. However, many countries, even in the globalizedeconomy, continue to have individual regulations and requirements forinternational transactions, and particularly financial transactions,which can lead to failed transactions where the originator fails toinclude all necessary information. Further, where the transactioninvolves multiple transactions, the entire batch of transactions may berejected due to missing information. This can result in the transactionsnot occurring in a timely fashion, which may have serious consequenceswhere the transactions are critical, such as in international finance.Additionally, fees may be imposed by the requesting financialinstitution (FI), as well as an FI associated with the originator.

Referring generally to the figures, systems and methods for providing aglobal transactions platform are shown in various embodiments. Accordingto various embodiments, a global transaction processing circuitassociated with an originating FI can evaluate the proposed transactionsand dynamically provide the originator with the requirements tosuccessfully complete the requested transaction. The global transactionprocessing circuit may further be configured to automatically evaluateeach requested transaction to determine if the transaction containssufficient information to be processed and accepted by the recipient FI.In some instances, the global transaction processing circuit may includea transaction correction tool to allow the originating FI toautomatically provide certain required information to complete thetransactions, where the originating FI has access to the requiredinformation.

According to various embodiments, as described in further detail below,providing systems and methods for evaluating, processing, anddynamically modifying international transaction, can provide an improvedinterface between parties in an international transaction by reducingtransactional failures associated with incomplete information beingprovided by the originator. By providing dynamically generatedinterfaces for individual transactions, additional value-addfunctionality can be achieved, as the originator can immediately realizewhat information is required for the transaction, and supply it. Thiscan reduce failed transactions by ensuring the proper information isprovided, thereby reducing time to complete the transaction, as well ascost associated with a failed transaction. Further, providing dynamiccorrection of some transactional errors can further reduce the number offailed transactions, especially where multiple transactions areinitiated by an originator at once. Accordingly, the embodimentsdescribed herein solve the technical and internet-centric problem ofproviding a global transactional platform to allow for easier, moreaccurate, and more reliable (i.e., completed a higher percentage of thetime the first time the transaction is submitted) internationaltransaction requests.

FIG. 1 is a block diagram of a global transaction system 100, accordingto an embodiment. The global transaction system 100 may include a userdevice 102 associated with a transaction originator 104. The originator104 may be an individual, or an entity, such as a corporation, FI,brokerage house, or any other entity which may initiate globaltransactions (e.g., a transfer of funds from a first account in a firstcountry to a recipient having a second account in a second country). Theglobal transaction system 100 may further include an originating FI 106including an originating FI computing system 108, a receiving FI 110including a receiving FI computing system 112, and a network 114. Theuser device 102, the originating FI computing system 108, and thereceiving FI computing system 112 may each include a computer system(e.g., one or more servers, each with one or more processing circuits),each including a processor and a memory. As described herein, theoriginating FI 106 maintains accounts in a first country, and thereceiving FI 110 maintains accounts in a second country that isdifferent than the first country. Accordingly, any described transfer offunds between the originating FI 106 and the receiving FI 110 areinternational or global transfers.

The processors may be implemented as application specific integratedcircuits (ASICs), one or more field programmable gate arrays (PFGAs), agroup of processing components, or other suitable electronic processingcomponents. The memory may be one or more devices (e.g., RAM, ROM, Flashmemory, hard disk storage, etc.) for storing data and/or computer codefor completing and/or facilitating the various processes describedherein. The memory may be or include non-transient volatile memory,non-volatile memory, and non-transitory computer storage media. Thememory may include database components, object code components, scriptcomponents, or any other type of information structure for supportingthe various activities and information structures described herein. Thememory may be communicably connected to the processor and includecomputer code or instructions for executing one or more processesdescribed herein.

The originating FI computing system 108 and/or the receiving FIcomputing system 112 may include a server-based computing system, forexample, comprising one or more networked computer servers that areprogrammed to perform the operations described herein. The originatingFI computing system 108 and/or the receiving FI computing system 112 maybe implemented as a distributed computer system, where each function isspread over multiple computer systems.

The originating FI computing system 108 and/or the receiving FIcomputing system 112 may be one or more centralized servers connected toone or more of the other listed components within the global transactionsystem 100 via the network 114. In some embodiments, the network 114 maybe an internet based network. For example, the components of the globaltransaction system 100 may all be in communication with a cloud-basednetwork, as will be described in more detail below. In some embodiments,the network connections between the components are wired networkconnections, such as a TCP/IP network. In other embodiments, the networkconnections may be wireless network, such as Wi-Fi, Wi-Max, cellular(3G, 4G, LTE, CDMA), LoRA, ZigBee, Near Field Communication (NFC),Bluetooth, or any other applicable wireless network protocols. In someembodiments, the originating FI computing system 108 and/or thereceiving FI computing system 112 may be hosted by a third-party.

The user device 102 may be any device associated with the originator 104that can communicate with the network 114, and/or the originating FI106. In some embodiments, the user device 102 may include a userinterface on an internet accessible website. In other embodiments, theuser device 102 may be a mobile device associated with the originator104. Example mobile devices can include smartphones (e.g., iPhone®,Android® phones, Windows® phones, etc.), tablet computers (e.g., iPad®,Android® tablet, Microsoft Surface®, etc.), laptop computers, wearabledevice, or any other device capable of communicating with the network114 and/or the originating FI 106. In one embodiment, the user device102 is used to provide access to the originating FI 106. For example,the user device 102 may communicate with the originating FI 106 via thenetwork 114.

The user device 102 includes a user interface 116, a network interfacecircuit 118, and an application manager 120. The user interface 116 maybe any interface providing inputs and outputs within the user device102. For example, the user interface 116 may be a touchscreen displayassociated with mobile device, such as a smartphone or tablet PC. Inother examples, the user interface 116 may be a combination of a displayand a separate input device, such as a keyboard. In still furtherexamples, the user interface 116 may be an audio interface, such as avirtual assistant such as Apple's® Siri,® or other virtual assistants.The network interface circuit 118 facilitates data communications to andfrom the network 114. The network interface circuit 118 may beconfigured to communicate wirelessly to the network 114, such as viaWi-Fi, Bluetooth®, NFC, ZigBee, IR, RF, cellular (3G, 4G, LTE, CDMA),etc. In other embodiments, the network interface circuit 118 maycommunicate with the network 114 via a wired connection, such as viaEthernet, a LAN, a WAN, Firewire, USB, or another applicable wiredinterface. In some embodiments, data passing through the networkinterface circuit 118 is encrypted.

The application manager 120 is configured to manage one or more softwareapplications (apps) associated with the user device 102. For example,the application manager 120 may manage an FI app 122. The FI app 122 maybe a mobile banking application, associated with an FI used by theoriginator 104, such as originating FI 106. In one embodiment, the FIapp 122 allows for direct communication between the user device 102 andthe originating FI 106. In further examples, the FI app 122 may be amobile wallet application. In one embodiment, the application manager120 processes requests from the network interface circuit 118 to executeone or more applications. For example, the network interface circuit 118may receive a request to open the FI app 122 to allow for theoriginating FI 106 to interface with the user device 102.

As described above, the originating FI computing system 108 isassociated with the originating FI 106. The originating FI 106 may be abank, a credit union, a brokerage house, a currency exchange, or anyother FI. The originating FI 106 is responsible for processing atransaction requested by the originator 104, such as a global financialtransaction (e.g. a financial transaction with a recipient in adifferent country than the originator 104). In some embodiments, theoriginator 104 may have an account established with the originating FI106. In other embodiments, the originator 104 may select the originatingFI 106 for a specific transaction based on the ability of theoriginating FI 106 to complete the transaction. Example transactions caninclude payments, money transfers, currency exchanges, credit swaps, orother transactions requiring funds to be transferred to or from arecipient in a different country than the originator 104.

The originating FI computing system 108 may process transaction requestspresented to the originating FI 106. For example, the originating FIcomputing system 108 may process all global transactions associated withthe originator 104. The originating FI computing system 108 may includea network interface circuit 124, an originator profile 126 and a globaltransaction processing circuit 128. The network interface circuit 124facilitates data communications to and from the network 114. The networkinterface circuit 124 may be configured to communicate wirelessly to thenetwork 114, such as via Wi-Fi, Bluetooth, NFC, ZigBee, IR, RF, cellular(3G, 4G, LTE, CDMA), etc. In other embodiments, the network interfacecircuit 124 may communicate with the network 114 via a wired connection,such as via Ethernet, a LAN, a WAN, Firewire, USB, or another applicablewired interface. In some embodiments, data passing through the networkinterface circuit 124 is encrypted.

The originator profile 126 may be configured to store a number ofcharacteristics associated with the originator 104. For example, theoriginator profile 126 may be generated when the originator 104 opens anaccount with the originating FI 106. However, in other embodiments, theoriginator profile 126 may be dynamically created at the time theoriginator 104 requests to make a financial transaction. In oneembodiment, the originator profile 126 may contain characteristicsassociated with the originator 104 such as personal identifyinginformation (name, address, social security number, etc.), financialinformation (checking accounts, savings accounts, credit card accounts,money market accounts, etc.), asset information, previous transactioninformation, or any other information related to interactions betweenthe originator 104 and the originating FI 106.

The global transaction processing circuit 128 is configured to processglobal transactions performed by the originating FI 106. In someembodiments, the global transaction processing circuit 128 can includemultiple sub-circuits used to perform aspects of the global transaction.As shown in FIG. 1, the global transaction processing circuit 128 caninclude a transaction form generation circuit 130, a transactionverification circuit 132, a transaction analysis circuit 134, atransaction correction circuit 136 and a transaction score generator138. The transaction form generation circuit 130 may be configured togenerate a form based on the transaction being requested by theoriginator 104. For example, the transaction form generation circuit 130may provide a dynamically generated form with specific informationrequests associated with a requested transaction. The dynamicallygenerated form can be provided to the originator 104 via the userinterface 116. However, in other embodiments, the dynamically generatedform may be provided to the originator 104 in other formats, such as viaphysical documents. In one example, the transaction form generationcircuit 130 may dynamically generate a form based on the transactiontype. For example, for transfer of funds a first form may be generated,while for a credit request, a second form may be generated. Further, thetransaction form generation circuit 130 may dynamically generate a formbased on the countries and/or entities involved in the transaction. Forexample, a transaction between an individual in the United States ofAmerica and an individual in India may require certain data, while thesame transaction between corporations may require still other data. Asanother example, a transaction between an individual in the UnitedStates of America and an individual in India may require certain data,while a transaction between an individual in the United States ofAmerica and an individual in Canada may require different information.By evaluating the transaction type and/or the parties involved, thetransaction form generation circuit 130 can provide a comprehensive formto the originator 104 to successfully perform the transaction. In otherembodiments, the transaction form generation circuit 130 may evaluatethe transaction being requested and provide the originator 104 with apre-defined form that best fits the requested transaction. For example,the transaction form generation circuit 130 may have access to arepository of previously generated forms, which the transaction formgeneration circuit 130 can select from based on analyzing the requestedtransaction. The transaction form generation circuit 130 can select thebest form based on certain criteria associated with the requestedtransaction, such as transaction type, transaction origin anddestination countries, originator 104 type, recipient or receiving FI110 type, etc.

The transaction verification circuit 132 is configured to verify thetransaction requested by the originator 104. For example, thetransaction verification circuit 132 may be configured to receiveinformation provided by the originator 104 regarding the requestedtransaction. In some arrangements, the originator 104 may provide theinformation via the user interface 116. For example, the originator 104may input data related to the transaction into a form generated by thetransaction form generation circuit 130. The originator 104 may thensubmit the generated form back to the originating FI computing system108, where it is interpreted by the transaction verification circuit132. The transaction verification circuit 132 may analyze thetransactional data provided by the originator 104 to determine if therequested transaction is a valid one. For example, the transactionverification circuit 132 may evaluate the current accounts of theoriginator 104 to ensure that the proper funds are available where thetransaction is a transfer of funds form the originator 104 to anotherparty. Further, the transaction verification circuit 132 may evaluatethe data provided by the originator 104 to ensure that the originator104 is in fact the person making the request. Additionally, thetransaction verification circuit 132 may query the receiving FI 110 toensure that the receiving FI 110 is capable of handling the transaction.In some arrangements, the transaction verification circuit 132 maydetermine if the receiving FI 110 is a valid FI, or if the receiving FI110 is a reputable FI.

In some arrangements, the transaction verification circuit 132 may onlydetermine if the general requirements associated with the requestedtransaction are met. The transaction information may then be provided tothe transaction analysis circuit 134. The transaction analysis circuit134 may be configured to provide additional analysis related to therequested transaction. For example, the transaction analysis circuit 134may evaluate transactional data such as transaction type, the origin ofthe transaction, the destination of the transaction, the originator 104and recipient party types, etc. Based on the evaluation, the transactionanalysis circuit 134 may determine if sufficient information has beenprovided by the originator 104 to perform the transaction. In somearrangements, the transaction analysis circuit 134 is configured toaccess one or more databases to determine all the information that isrequired to complete the requested transaction, based on the evaluatedtransactional data.

In other arrangements, the transaction analysis circuit 134 isconfigured to communicate with one or more databases or other repositoryto access previous transactions with similar characteristics to therequested transaction. For example, where the transaction is fundtransfer between an individual in the U.S.A. and a company in India, thetransaction analysis circuit 134 may access a database containinginformation related to similar transaction that were performed in thepast. The transaction analysis circuit 134 may then use the previoussimilar transactions to analyze the requested transaction to determineif the requested transaction contains the required information to besuccessfully processed. In some arrangements, the transaction analysiscircuit 134 may reject the requested transaction where the requestedtransaction is likely to be deemed deficient by the receiving FI 110, orthe originating FI 106. In some arrangements, the transaction analysiscircuit 134 instructs the originating FI computing system 108 tocommunicate to the originator 104 that the requested transaction isdefective. In one embodiment, the originating FI computing system 108may inform the originator 104 that the requested transaction isdefective by transmitting a message to the user device 102 via thenetwork interface circuit 124. In other examples, the transactionanalysis circuit 134 may note any potential defects within thetransaction request and provide the information to the transactioncorrection circuit 136.

The transaction correction circuit 136 may be configured to receive theanalysis of the requested transaction from the transaction analysiscircuit 134. For example, the transaction analysis circuit 134 maytransmit a list of missing information to the transaction correctioncircuit 136. In other examples, the transaction analysis circuit 134transmits a report indicating the defective portions of the requestedtransaction to the transaction correction circuit 136. The transactioncorrection circuit 136 analyzes the information received from thetransaction analysis circuit 134 and determines if the defects in therequested transaction can be automatically corrected. For example, wherethe originator 104 failed to provide certain personal identifyinginformation (PII) in the requested transaction, the transactioncorrection circuit 136 may be able to automatically provide thatinformation to allow the requested transaction to be completed. In oneembodiment, the transaction correction circuit 136 is in communicationwith the originator profile 126, allowing the transaction correctioncircuit 136 access to information related to the originator 104. Thetransaction correction circuit 136 may then utilize that information tocorrect any defects within the requested transaction, where possible. Insome arrangements, the transaction correction circuit 136 may obtain theinformation required to correct the defects of the requested transactionand send a message to the originator 104, such as via the user device102, explaining the modifications, and requesting permission to submitthe corrected transaction request. In other arrangements, the originator104 may initially what define what, if any, PII within the originatorprofile 126 may be automatically used by the global transactionprocessing circuit 128 without requiring permission from the originator104. This can allow the transaction correction circuit 136 toautomatically correct certain defects within a requested transaction,thereby increasing the efficiency of the requested transaction, as wellas making the transaction process easier on the originator 104.

In some examples, the transaction correction circuit 136 may not be ableto automatically correct potential defects within the requestedtransaction identified by the transaction analysis circuit 134. Wherethe transaction correction circuit 136 is unable to automaticallycorrect the defects within requested transaction, the transactioncorrection circuit 136 may determine what additional information isneeded to correct the defects associated with the requested transaction.The transaction correction circuit 136 may then provide a list of therequired information to the originator 104, such as via the user device102. In some arrangements, the transaction correction circuit 136 may beconfigured to generate one or more inputs, such as dialog boxes, thatrelate to the information required to correct the defects within therequested transaction, thereby allowing the originator 104 to providethe required information. The originator 104 can then submit theinformation back to the originating FI computing system 108 forprocessing. In some arrangements, the information is provided to theuser via the user device 102. For example, the transaction correctioncircuit 136 may be configured to generate the one or more inputs, anddisplay the inputs on the user interface 116. In some arrangements, theone or more inputs may be displayed via the FI app 122.

The transaction score generator 138 may be configured to assign a scoreto each transaction requested by the originator 104. In one embodiment,the score may be associated with the number of defects associated withthe each requested transaction. For example, the score may reflect thenumber of defects in a given requested transactions, such that a scoreof four would indicate that there were four defects. In other examples,the score may be a weighted numerical value that is based on multipleparameters, such as number of defects, complexity of requestedtransaction, amount of transaction, etc. The parameters may be evaluatedand a number generated associated with a score of the requestedtransactions. The score may be a numerical value on a sliding scale,such as one to ten, where ten represents a high-quality transactionrequest, and one equals the lowest quality transaction request. Whilethe above examples describe a numerical score, other types of scores maybe generated such as letter scores (e.g. A, B, C, D, F), word scores(e.g. excellent, good, average, below average, poor, etc.), or otherscore types that convey an evaluation of a given requested transaction.

The scores may be used to provide a baseline of financial competenceassociated with the originator 104. For example, if the originator 104consistently achieves low scores, indicating multiple defects associatedwith a requested transaction, the global transaction processing circuit128 may modify the information requested from the originator 104 beforea transaction is processed. In other arrangements, if the originator 104consistently achieves low scores, indicating multiple defects associatedwith a requested transaction, the global transaction processing circuit128 may restrict the types of transactions that the originator 104 isallowed to request. For example, where the originator 104 hasconsistently low scores, the global transaction processing circuit 128may not allow the originator 104 to perform batch transactions. In otherarrangements, if the originator 104 has consistently high scores, theglobal transaction processing circuit 128 may allow the originator 104to perform certain transactions, such as batch transactions. In somearrangements, the transaction score generator 138 may generate scoresfor different types of transactions. For example, the originator 104 mayhave high scores for transaction to one country, but low scores fortransactions to another country. Accordingly, the global transactionprocessing circuit 128 can receive the scores from the transaction scoregenerator 138, and modify how transactions to different countries arehandled. For example, the transaction form generation circuit 130 mayhighlight a field that is commonly not provided, or incorrectlyprovided. This can help to ensure that the originator 104 provides thecorrect information initially to the originating FI 106 when requestingthe transaction.

Still referring to FIG. 1, the receiving FI 110, as described above,includes a receiving FI computing system 112. The receiving FI computingsystem 112 includes a network interface circuit 140 and a transactionverification circuit 142. The network interface circuit 140 facilitatesdata communications to and from the network 114. The network interfacecircuit 140 may be configured to communicate wirelessly to the network114, such as via Wi-Fi, Bluetooth, NFC, ZigBee, IR, RF, Cellular (3G,4G, LTE, CDMA), etc. In other arrangements, the network interfacecircuit 140 may communicate with the network 114 via a wired connection,such as via Ethernet, a LAN, a WAN, Firewire, USB, or another applicablewired interface. In some arrangements, data passing through the networkinterface circuit 140 is encrypted. The transaction verification circuit142 is configured to process a requested transaction received from theoriginating FI computing system 108. The transaction verificationcircuit 142 can evaluate the received requested transaction and verifythat the transaction is valid.

Turning now to FIG. 2, a block diagram illustrating an example financialtransaction request 200 is shown. The financial transaction request 200includes data blocks, such as an originator identity information block202, transaction specific information block 204, and a recipientspecific information requirements block 206. However, it is contemplatedthat other financial transaction requests may include more or fewer datablocks, as required. The originator identity information block 202 mayinclude originator PII 208, originator FI information 210, and otheroriginator identity information 212. However, it is contemplated thatthe originator identity information block 202 may include moreinformation or less information, as needed. The various data blocks maybe packaged in a single data file, which may be encrypted.

The originator PII 208 can include information about the originator 104that serves to identify the originator 104. This can include PII such associal security number, driver's license number, passport number, photoID, biometric data (fingerprints, eye scans, voice recordings), phonenumber, or other PII which serves to identify the originator 104. Theoriginator FI information 210 can include information relating to the FIassociated with the originator 104, such as FI name, address, tax IDnumber, phone number, FDIC number, bank identification number (BIN),routing number, or other information relating to the identity of theoriginator 104 FI. The other originator identity information 212 mayinclude any other information related to the originator 104 that may berequired to complete a financial transaction.

The transaction specific information block 204 may include one or moreof transaction type information 214, transaction amount information 216,account information 218, and recipient information 220. The transactiontype information 214 may include data related to the type of transactionbeing requested. Example transaction types can include transfers offunds, transfers of other financial instruments (securities, bonds,etc.), requests for payment, credit based transactions, loan requests,invoice payments, currency swap, etc. The transaction amount information216 may include data related to a value associated with the transaction.For example, the value of money being transferred, the amount of creditrequested, the amount of currency being exchanged, etc. The accountinformation 218 can include information relating to an accountassociated with the originator 104, such as account numbers, routingnumbers, account balances, or other information related to the accountof the originator 104 to be used to process the transaction. Finally,the recipient information 220 may include data related to the intendedrecipient associated with the requested transaction. The recipientinformation 220 may include the name of the recipient, an account of therecipient, a financial institution associated with the recipient, orother information related to the recipient. In one embodiment, therecipient information 220 includes information about a countryassociated with the recipient. The recipient information 220 may furtherinclude information related to the FI associated with the recipient. Forexample, information such as FI name, address, tax ID number, phonenumber, FDIC number, bank identification number (BIN), routing number,or other information relating to the identity of the receiving FI 110may be included in the recipient information 220.

The recipient specific information requirements block 206 may includeinformation related specifically to the recipient. Specifically, therecipient specific information requirements block 206 may include datathat is required by the recipient to process the requested financialtransaction. For example, the recipient specific informationrequirements block 206 may include country specific information 222,receiving FI specific information 224, and/or other recipient specificinformation 226. The country specific information 222 may includeinformation that is required for specific transaction in a givencountry. For example, if the request is a payment to a recipient inIndia, the financial transaction request requires a purpose of paymentcode. In other examples, other countries may impose specificrequirements on the financial transaction request 200, such as paymentpurposes, what the payment is for, the origin of the funds used in thepayment, etc. The receiving FI specific information 224 may includeinformation specifically required by the receiving FI 110, such asadditional PII associated with the originator 104, specific currenciesto be used, etc. Finally, other recipient specific information 226includes all other information required by the recipient to complete thetransaction. The other recipient specific information 226 may includeinformation specifically requested by the recipient, such as anassociated purchase or transaction number, requested currency, etc.

FIG. 3 is a flow chart illustrating a transaction request correctionprocess 300, according to some embodiments. For clarity and brevity, themethod 300 is discussed below in connection with the system described inFIG. 1. The method 300 is performed by the originating FI computingsystem 108. The method 300 begins when the originating FI computingsystem 108 receives a transaction request at 304. In one example, theoriginator 104 may enter a transaction request which is then provided tothe originating FI computing system 108. In one embodiment, theoriginator 104 may enter the transaction request via the user device102. For example, the originator 104 may enter the transaction requestvia the FI app 122 on their mobile device. In some arrangements, the FIapp 122 may be configured to provide a custom form based on thetransaction type for the customer to complete in order to enter thetransaction request. The creation of custom forms will be described inmore detail below. In other arrangements, the originator may enter thetransaction using an interface on a banking device, such as an automaticteller machine (ATM) or an automatic banking machine. The originator 104may provide transaction data such as originator identity information,transaction specific information (e.g. transaction amount, accounts,etc.), and recipient specific information, such as recipientidentification, recipient location, etc, within the transaction request.

The originator 104 may transmit the request to the originating FI 106.In one embodiment, the originator 104 can transmit the request via theuser device 102. For example, the originator 104 may transmit therequest to the originating FI 106 via the FI app 122. After receivingthe transaction request at 304, the originating FI 106 validates theassociated transaction data at 306. In one embodiment, the originatingFI 106 may determine if the transaction is valid via the transactionverification circuit 132 and/or the transaction analysis circuit 134, asdescribed above. Specifically, the originating FI 106 looks to thetransaction data provided by the originator 104, along with the type oftransaction being requested. For example, the originating FI 106 maydetermine the type of transaction and the recipient of the transactionbased on information provided within the transaction request. Based onthe transaction type and intended recipient, the originating FI 106 canvalidate the transaction data.

The originating FI 106 determines if the transaction request is validbased on the provided transaction data at 308. The originating FI 106may determine that the request is valid where sufficient information isprovided to complete the transaction. In further examples, theoriginating FI 106 may evaluate the transaction request to ensure thatthe information provided is correct. If the originating FI 106determines that the information provided does not contain any errors,the originating FI 106 may determine that the request is valid. If thetransaction is valid, the originating FI 16 processes the transaction at310, and transmits the processed transaction to the receiving FI 110 at312. In one embodiment, processing the transaction includes organizingthe data form the transaction request into a data packet recognizableand readable by the receiving FI 110. For example, the originating FI106 may process the data from the transaction request such that the datais configured as a Society for Worldwide Interbank FinancialTelecommunications (SWIFT) message. A SWIFT message can be used todirect the transaction message to the receiving FI 110 in a manner thatthe receiving FI 110 will be able to understand. In other examples, thedata may be configured as a Telex message, a Fedwire message, a Ripplemessage, a CHIPS message, or any other message used for communicatingtransactions between the originating FI 106 and the receiving FI 110.Processing the request may further include authorizing a transfer offunds from an account associated with originator 104 to the receiving FI110. Additionally, processing the request may further includedetermining a path to the receiving FI 110, via one or moreintermediaries.

In some embodiments, one or more intermediaries may be between theoriginating FI 106 and the receiving FI 110, particularly where theoriginating FI 106 and the receiving FI 110 are in different countriesand do not have an existing business relationship. The intermediariesmay be institutions that have a business relationship with both theoriginating FI 106 and the receiving FI 110, and that can facilitate thecompletion of the requested transaction between the two. Theintermediaries may be FIs, brokerage houses, third party transactionfacilitators, governmental agencies, or other institutions that arecapable of facilitating financial transactions between the originatingFI and the receiving FI. In some examples, multiple intermediaries maybe required to get a transaction from the originating FI 106 to the tothe receiving FI 110, and vice-versa. In some instances, theintermediaries may also have specific information requests which theoriginating FI 106 will need to provide. The originating FI 106 may beaware of the information required to complete the transaction usingintermediaries, and may require the originator 104 to provide additionalinformation if needed, as described below.

If the originating FI 106 determines that the transaction is not validat 308, the originating FI 106 determines if the request can beautomatically fixed at 314. In one embodiment, the transactioncorrection circuit 136 evaluates the defects associated with thereceived request to determine if the request can be automatically fixed.For example, where the transaction is missing information, such as PIIinformation, the transaction correction circuit 136 may access theoriginator profile 126, as described above, to determine if theinformation is available to be used in correcting any defects associatedwith the transaction request. If an automatic fix is determined to beavailable, the originating FI 106 modifies the received transactionrequest at process block 316. Modifying the requested transaction caninclude providing the missing information previously provided by theoriginator 104. Once the requested transaction has been modified, andthe defects corrected, the transaction is processed at 310, andtransmitted to the receiving FI 110 at 312.

If the originating FI 106 determines that an automatic fix is notavailable, the originating FI 106 determines if a manual fix isavailable 318. If a manual fix is not available, such as when thedefects are too significant to allow for simple corrections to be made,the transaction request is returned to the originator 104 at 320. Insome arrangements, the transaction request may be returned with amessage indicating that the transaction request failed. In somearrangements, the message may further provide a list of reasons why therequest failed to allow the originator 104 to correct the defects in asubsequent transaction request. If the originating FI 106 determinesthat a manual fix is available, the originating FI 106 may return thetransaction request to the originator 104 with an ability to cure thedefects at 322. For example, the request may be returned along with oneor more inputs that allow the originator 104 to provide the requiredinformation, and cure the subsequent defects. In one embodiment, thetransaction request is returned via the FI app 122, along withinstructions to provide additional information required to complete thetransaction. The originator 104 may then transmit the request back tothe originating FI 106 at 304.

FIG. 4 is a process chart illustrating a process for processing batchtransaction 400, according to some embodiments. For clarity and brevity,the method 400 is discussed below in connection with the systemdescribed in FIG. 1. The originating FI 106 receives a batch oftransaction requests at 404. The originator 104 may enter a batch oftransaction requests. For example, the originator 104 may submit anumber of payments to for paying various invoices or other bills. Inother examples, the originator 104 may submit multiple fund transfers atone time. In one embodiment, the originator 104 may enter multipletransaction requests via the user device 102 as a batch transactionrequest. For example, the originator 104 may enter the transactionrequests via the FI app 122. In other arrangements, the originator 104may upload the transaction requests to the originating FI 106 as asingle file (e.g., a single file containing information relating tomultiple discrete transactions). In other arrangements, the transactionrequests may be entered into the originating FI 106, such as via the FIapp 122, one at a time, and then submitted together once all thetransaction requests have been entered. In some arrangements, the FI app122 may be configured to provide a custom form based on the transactiontype for the originator 104 to complete in order to enter a transactionrequest. For example, if the originator 104 indicates that they wouldlike to make a payment, the FI app 122 may provide a custom form withgeneral information required to process a payment. The originator 104may then be able to enter the data directly into the FI app 122 via theuser interface 116. The originator 104 may provide transaction data suchas originator identity information, transaction specific information,and recipient specific information, as described above, within thecustom form to generate the transaction request. In other arrangements,the originator 104 may provide basic transaction data associated witheach of the transaction requests.

Additionally, the originator 104 can transmit the transaction requeststo the originating FI 106. In one embodiment, the originator 104 cantransmit the transaction requests via the user device 102. For example,the originator 104 may transmit the transaction requests to theoriginating FI 106 via the FI app 122. The originating FI validates thetransaction data associated with each transaction request at 406. In oneembodiment, the originating FI 106 may determine if the transaction datais valid via the transaction verification circuit 132 and/or thetransaction analysis circuit 134, as described above. Specifically, theoriginating FI 106 looks to the transaction data provided by theoriginator 104, along with the type of transactions being requested. Forexample, the originating FI 106 may determine the type of transactionsand the recipient of the transactions based on information providedwithin the transaction requests. Based on the transaction type andintended recipient, the originating fi 106 can validate the transactiondata for the individual transaction requests.

The originating fi 106 determines if each transaction request is validbased on the provided transaction data at 408. If a transaction isvalid, the originating FI 106 processes the transaction at 410, andtransmits the processed transaction to the receiving FI 110 at 412. Ifthe originating FI 106 determines that the transaction is not valid at408, the originating FI 106 determines if the request can beautomatically fixed at 414. In one embodiment, the transactioncorrection circuit 136 evaluates the defects associated with thereceived request to determine if the request can be automatically fixed.For example, where the transaction is missing information, such as PIIinformation, the transaction correction circuit 136 may access theoriginator profile 126, as described above, to determine if theinformation is available to be used in correcting any defects associatedwith the transaction request. If an automatic fix is determined to beavailable, the originating FI 106 modifies the transaction request tocure the defects at 416. Modifying the requested transaction can includeproviding the missing information previously provided by the originator104. Once the requested transaction has been modified, and the defectscorrected, the transaction is processed at process block 410, andtransmitted to the receiving FI 110 412.

If the originating FI 106 determines that an automatic fix is notavailable, the originating FI 106 determines if a manual fix isavailable at 418. If the originating FI 106 determines that a manual fixis available, the originating FI 106 may return the transaction requestto the originator 104 with an ability to cure the defects at 420. Forexample, the transaction request may be returned along with one or moreinputs that allow the originator 104 to provide the requiredinformation, and cure the subsequent defects. In one embodiment, thetransaction request is returned via the FI app 122, along withinstructions to provide additional information required to complete thetransaction. The originator 104 may then transmit the request back tothe originating FI 106 at 404. If a manual fix is not available, such aswhen the defects are too significant to allow for simple corrections tobe made, the transaction request is returned to the originator 104 as afailed transaction at 422. In some arrangements, the transaction requestmay be returned with a message indicating that the transaction requestfailed. In some arrangements, the message may further provide a list ofreasons why the request failed to allow the originator 104 to correctthe defects in a subsequent transaction request.

After the transactions have been processed, the originating FI 106 cangenerate a score associated with each transaction request at 424. In oneembodiment, the transaction score generator 138 may generate the scoreassociated with each transaction. The score can be determined based onthe number and types of defects associated with each transactionrequest. In one embodiment, a low score may indicate that there weresignificant defects associated with the transactions, and a high scoremay indicate that the transaction requests were relatively defect free,or that the defects were minor. In addition to the number and type ofdefects, the score may also be dependent on the type and complexity ofthe individual transaction requests presented by the originator 104. Thescore may be used by the originating FI 106 to modify the interactionswith the originator 104. For example, if the originator 104 has lowscores when processing a large batch of transaction requests, theoriginating FI 106 may limit the number of transaction requests that canbe made at one time by the originator 104. In other arrangements, theoriginating FI 106 may modify the transaction request forms provided tothe originator 104 to ensure that the proper information is included inthe transaction requests. The score may also be used to provide aconfidence score to the originator 104. For example, if the originatorsubmits a batch transaction, the originating FI computing system 108 mayreturn a score indicative of the chances of the transactions beingprocessed without requiring repair or re-submissions. Based on thescore, the originator can elect whether or not to proceed with thetransactions request in their current state.

FIG. 5 is a flow diagram illustrating an example implementation 500 ofthe method shown in FIG. 3. For clarity and brevity, the implementation500 is discussed below in connection with the system described inFIG. 1. Specifically, in regards to the originator 104, the originatingFI 106 and the receiving FI 110. The originator 104 originates thetransaction at 502. In one embodiment, the originator 104 can originatethe transaction by providing information to the originating FI 106. Theinformation may include transactional data, such as originator identityinformation, transaction specific information, and/or recipient specificinformation requirements, as described above. However, it iscontemplated that the transactional data may include additional data. Inone embodiment, the originator 104 may provide the transactional datavia the user device 102. For example, the originator 104 may enter allthe information associated with the transaction using the FI app 122. Insome arrangements, the originator 104 may simply provide a request toperform a certain type of transaction, along with basic data related tothe transaction, such as the type of transaction, the parties, andinformation associated with the parties. However, in other arrangementsthe originator 104 may provide the data using other means, such as via aweb-portal associated with the originating FI 106, or even by providingpaper documents directly to the originating FI 106.

The originating FI 106 can review the transactional data provided by theoriginator 104 at 504. For example, the originating FI 106 may evaluatethe type of transaction to determine what additional information mightbe necessary. The originating FI 106 may also evaluate other parametersassociated with the transaction request, such as the parties, and thecountries involved in the transaction. In one embodiment, the review isperformed by the transaction verification circuit 132. In otherarrangements, the transaction form generation circuit 130 may review thetransactional data provided by the originator 104. Based on the reviewby the originating FI 106, a custom transaction form 506 may begenerated at 508. The custom transaction form 506 may be generated bythe transaction form generation circuit 130. The custom transaction form506 may be generated to include fields associated with additional datarequired based on the review of the provided transactional data at 504.For example, the custom transaction form 506 may be configured torequest additional data based on the determined transaction type,parties, countries involved, or any other transactional data provided bythe originator 104. For example, certain countries may requireadditional information to complete a given transaction, based on thetransaction type, such as India. India requires a payment purpose beprovided when the transaction is a payment. Thus, the custom transactionform 506 may be generated to include a field for “payment purpose” toensure that the information is provided by the originator 104. Othercountries and/or other transaction types also may require additionalinformation, and the above examples should not be limited to anyparticular country and/or transaction type discussed herein. The customtransaction form 506 is provided to the originator 104, who completesthe custom transaction form 506 at 510. For example, the originator 104may input additional transactional data required by the customtransaction form 506 to complete the transaction.

The originator 104 transmits the custom transaction form 506 containingthe additional transactional data as transaction data packet 514 at 512.In one embodiment, the transaction data packet 514 includes all theinformation required to complete the transaction. For example, thetransaction data packet 514 can include transaction data such asoriginator identity information, transaction specific information, andrecipient specific information requirements. The originating FI 106receives the transaction data packet 514 and processes the transactionat 516. In one embodiment, the originating FI 106 processes thetransaction based on the transactional data within the transaction datapacket 514. Further, processing the transaction may include determiningif the transaction is valid. In one embodiment, the originating FI 106determines if the transaction is valid via the transaction verificationcircuit 132 and/or the transaction analysis circuit 134, as describedabove. Specifically, the originating FI 106 looks to the transactiondata provided by the originator 104, along with the type of transactionbeing requested. For example, the originating FI 106 may determine thetype of transaction and the recipient of the transaction based oninformation provided within the transaction data packet 514. Based onthe transaction type and intended recipient, the originating FI 106 canvalidate the transaction data.

The originating FI 106 determines if the transaction is valid, based onthe data in the transaction data packet 514 at 518. Similar to above,the originating FI 106 may utilize the transaction verification circuit132 and/or the transaction analysis circuit 134 to determine if thetransaction is valid. If the originating FI 106 determines that thetransaction is valid at 518, the originating fi 106 transmits aprocessed transaction data packet 520 to the receiving FI 110. Theprocessed transaction data packet 520 may include all the transactiondata required to complete the transaction. In some arrangements, theprocessed transaction data packet 520 includes all the informationrequired to complete the transaction as understood by the originating FI106. In some arrangements, the originating FI 106 may be incommunication with the receiving FI 110 to ensure that all requiredinformation is provided prior to transmitting the processed transactiondata packet 520. Once the receiving FI 110 receives the processedtransaction data packet 520, the transaction is completed at 522.

If the originating FI 106 determines that the transaction is not validat 518, the originating FI 106 then determines if the error isautomatically repairable 524. In one embodiment, the transactioncorrection circuit 136 evaluates the defects associated with thereceived request to determine if the transaction request can beautomatically repaired. For example, where the transaction is missinginformation, such as PII information, the transaction correction circuit136 may access the originator profile 126, as described above, todetermine if the information is available to be used in correcting anydefects associated with the transaction request. If an automatic fix isdetermined to be available, the originating FI 106 repairs thetransaction information (i.e. the data within the transaction datapacket 514) to cure the defects at 526. Modifying the requestedtransaction can include providing the missing information previouslyprovided by the originator 104. Once the requested transaction has beenrepaired, and the defects corrected, the originating FI 106 transmits arepaired processed transaction data packet 528 to the receiving FI 110.The receiving FI 110 may receive the repaired processed transaction datapacket 528 and complete the transaction at 522, as described above.

If the originating FI 106 determines that an automatic fix is notavailable, the originating FI 106 generates an error report 530. Theerror report 530 may be transmitted to the originator 104. For example,the error report 530 may be transmitted to the user device 102, foraccessing by the originator 104. In some arrangements, the error report530 may provide an indication that the transaction request is manuallyrepairable. If the originating FI 106 determines that the transaction ismanually repairable, the originating FI 106 may provide instructionswithin the error report 530 regarding how the originator 104 can repairthe transaction request. In one embodiment, the error report 530 may beconfigured to include one or more inputs that allow the originator 104to provide the required information, and cure the subsequent defects. Atprocess block 532, the originator 104 may manually repair thetransaction by providing the additional information requested in theerror report 530. The originator 104 may then generate a transactiondata packet 514 and transmit the transaction data packet 514 to theoriginating FI 106, as previously described above. The transaction datapacket 514 may then be processed at process block 516 to determine ifthe transaction is valid.

FIG. 6 is a flow diagram illustrating an example implementation 600 ofthe method shown in FIG. 4. For clarity and brevity, the implementation600 is discussed below in connection with the system described inFIG. 1. Specifically, in regards to the originator 104, the originatingFI 106 and the receiving FI 110. The originator 104 originates a groupof transactions, herein referred to as a batch transaction at 602. Inone embodiment, the originator 104 can originate the transaction byproviding one or more batch transaction data packets 604 to theoriginating FI 106. The batch transaction data packets 604 may includetransactional data for each transaction within the batch transaction,such as originator identity information, transaction specificinformation, and/or recipient specific information requirements, asdescribed above. However, it is contemplated that the batch transactiondata packets 604 may include more data or less data, as applicable. Inone embodiment, the originator 104 may provide the batch transactiondata packets 604 via the user device 102. For example, the originator104 may enter all the information associated with the transaction usingthe FI app 122. In some arrangements, the batch transaction data packets604 may simply include a request to perform a certain type oftransaction, along with basic data related to the transaction, such asthe type of transaction, the parties, and information associated withthe parties. However, in other arrangements the originator 104 mayprovide the batch transaction data packets 604 using other means, suchas via a web-portal associated with the originating FI 106, or even byproviding paper documents directly to the originating FI 106.

The originating FI 106 can review the batch transaction data packets 604provided by the originator 104 at 606. For example, the originating FI106 may evaluate the type of transaction to determine what additionalinformation might be necessary. The originating FI 106 may also evaluateother parameters associated with the batch transaction data packets 604,such as the parties, and the countries involved in the transaction. Inone embodiment, the review is performed by the transaction verificationcircuit 132. In other arrangements, the transaction form generationcircuit 130 may review the transactional data provided by the originator104.

Once the batch transaction data packets 604 have been reviewed, theoriginating FI 106 processes each transaction within the batchtransaction at 608. In one embodiment, the originating FI 106 processesthe transaction based on the transactional data within the batchtransaction data packets 604. Further, processing the transaction mayinclude determining if the transactions are valid. In one embodiment,the originating FI 106 determines if the transaction is valid via thetransaction verification circuit 132 and/or the transaction analysiscircuit 134, as described above. Specifically, the originating FI 106looks to the transaction data provided by the originator 104 in thebatch transaction data packets 604, along with the type of transactionbeing requested. For example, the originating FI 106 may determine thetype of transaction and the recipient of the transaction based oninformation provided within the batch transaction data packets 604.Based on the transaction type and intended recipient, the originating FI106 can validate the transaction data.

The originating FI 106 determines if the transactions are valid, basedon the data in the batch transaction data packets 604 at 610. Similar toabove, the originating FI 106 may utilize the transaction verificationcircuit 132 and/or the transaction analysis circuit 134 to determine ifthe transaction is valid. In one embodiment, the originating FI 106determines if each transaction within the batch transaction is valid onan individual basis. If the originating FI 106 determines that atransaction is valid at process block 610, the originating FI 106transmits a processed transaction data packets 612 to the receiving FI110 for each valid transaction. The processed transaction data packets612 may include all the transaction data required to complete thetransaction. In some arrangements, the processed transaction datapackets 612 include all of the information required to complete thetransaction as understood by the originating FI 106. In somearrangements, the originating FI 106 may be in communication with thereceiving FI 110 to ensure that all required information is providedprior to transmitting the processed transaction data packets 612. Oncethe receiving FI 110 receives the processed transaction data packets612, the transaction is completed at 614.

If the originating FI 106 determines that one or more transactions arenot valid at 610, the originating FI 106 then determines if the error isautomatically repairable at 616. In one embodiment, the transactioncorrection circuit 136 evaluates the defects associated with thereceived request to determine if the request can be automaticallyrepaired. For example, where the transaction is missing information,such as PII information, the transaction correction circuit 136 mayaccess the originator profile 126, as described above, to determine ifthe information is available to be used in correcting any defectsassociated with the transaction request. If an automatic fix isdetermined to be available, the originating FI 106 repairs thetransaction information (i.e. the data within the batch transaction datapackets 604) to cure the defects at 618. Modifying the requestedtransactions can include providing the missing information previouslyprovided by the originator 104. Once the requested transaction has beenrepaired, and the defects corrected, the originating FI 106 transmits arepaired processed transaction data packet 620 to the receiving FI 110for each repaired transaction. The receiving FI 110 may receive therepaired processed transaction data packet 620 and complete thetransaction at 614, as described above.

Additionally, once the originating FI 106 repairs the transactions at618, the originating FI 106 can then generate a transactional scorecard622 at 624. The transactional scorecard 622 may include a scoreindicating a financial competence of the originator 104 based on theprocessed transactions. In one embodiment, the transaction scoregenerator 138 is configured to generate a scorecard for each transactionrequested by the originator 104. In one embodiment, the score isassociated with the number of defects associated with the each requestedtransaction. The scores may be used to provide a baseline of financialcompetence associated with the originator 104. For example, if theoriginator 104 consistently achieves low scores, indicating multipledefects associated with a requested transaction, the originating FI 106may modify the information requested from the originator 104 before atransaction is processed. In other arrangements, if the originator 104consistently achieves low scores, indicating multiple defects associatedwith a requested transaction, the originating FI 106 may restrict thetypes of transactions that the originator 104 is allowed to request. Forexample, where the originator 104 has consistently low scores, theoriginating FI 106 may not allow the originator 104 to perform batchtransactions. In other arrangements, if the originator 104 hasconsistently high scores, the originating FI 106 may allow theoriginator 104 to perform certain transactions, such as batchtransactions in the future. In some arrangements, the transaction scoregenerator 138 generates scores for different types of transactions. Forexample, the originator 104 may have high scores for transaction to onecountry, but low scores for transactions to another country. Thus, theoriginating FI 106 may require the originator 104 to provide additionalinformation when requesting transactions with a country associated witha low score. For example, the transaction form generation circuit 130may highlight a field associated with data that is commonly notprovided, or incorrectly provided. This can help to ensure that theoriginator 104 provides the correct information initially to theoriginating FI 106 when requesting the transaction.

If the originating FI 106 determines that an automatic fix is notavailable at 616, the originating FI 106 generates an error report 626for each transaction that cannot be automatically repaired. The errorreport 626 can be transmitted to the originator 104. For example, theerror report 626 may be transmitted to the user device 102, foraccessing by the originator 104. In some arrangements, the error report626 may provide an indication that the transaction request is manuallyrepairable. If the originating FI 106 determines that the transaction ismanually repairable, the originating FI 106 may provide instructionswithin the error report regarding how the originator 104 can repair thetransaction request. In one embodiment, the error report 626 may beconfigured to include one or more inputs that allow the originator 104to provide the required information, and cure the subsequent defects. Atprocess block 628, the originator 104 may manually repair thetransaction by providing the additional information requested in theerror report 626. The originator 104 may then generate a repairedtransaction data packet 630 for each repaired transaction, and transmitthe repaired transaction data packet 630 to the originating FI 106, aspreviously described above. The repaired transaction data packet 630 maythen be processed at 608 to determine if the transaction is valid. Insome instances, the only way to repair the transaction is for theoriginator 104 to originate a new transaction, which may be indicatedwithin the error report. For example, where the errors are toosubstantial to be repaired, the error report can indicate that the erroris not repairable, and provide an indication to the originator 104 oftheir critical, as well as non-critical, errors were to allow for theoriginator 104 to correct the defects in a subsequent transactionrequest.

The embodiments described herein have been described with reference todrawings. The drawings illustrate certain details of specificembodiments that implement the systems, methods and programs describedherein. However, describing the embodiments with drawings should not beconstrued as imposing on the disclosure any limitations that may bepresent in the drawings.

It should be understood that no claim element herein is to be construedunder the provisions of 35 U.S.C. § 112(f), unless the element isexpressly recited using the phrase “means for.”

As used herein, the term “circuit” may include hardware structured toexecute the functions described herein. In some embodiments, eachrespective “circuit” may include machine-readable media for configuringthe hardware to execute the functions described herein. The circuit maybe embodied as one or more circuitry components including, but notlimited to, processing circuitry, network interfaces, peripheraldevices, input devices, output devices, sensors, etc. In someembodiments, a circuit may take the form of one or more analog circuits,electronic circuits (e.g., integrated circuits (IC), discrete circuits,system on a chip (SOCs) circuits, etc.), telecommunication circuits,hybrid circuits, and any other type of “circuit.” In this regard, the“circuit” may include any type of component for accomplishing orfacilitating achievement of the operations described herein. Forexample, a circuit as described herein may include one or moretransistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR,etc.), resistors, multiplexers, registers, capacitors, inductors,diodes, wiring, and so on).

The “circuit” may also include one or more dedicated processorscommunicatively coupled to one or more dedicated memory or memorydevices. In this regard, the one or more dedicated processors mayexecute instructions stored in the dedicated memory or may executeinstructions otherwise accessible to the one or more dedicatedprocessors. In some embodiments, the one or more dedicated processorsmay be embodied in various ways. The one or more dedicated processorsmay be constructed in a manner sufficient to perform at least theoperations described herein. In some embodiments, the one or morededicated processors may be shared by multiple circuits (e.g., circuit Aand circuit B may comprise or otherwise share the same processor which,in some example embodiments, may execute instructions stored, orotherwise accessed, via different areas of memory). Alternatively, oradditionally, the one or more dedicated processors may be structured toperform or otherwise execute certain operations independent of one ormore co-processors. In other example embodiments, two or more processorsmay be coupled via a bus to enable independent, parallel, pipelined, ormulti-threaded instruction execution. Each processor may be implementedas one or more general-purpose processors, application specificintegrated circuits (ASICs), field programmable gate arrays (FPGAs),digital signal processors (DSPs), or other suitable electronic dataprocessing components structured to execute instructions provided bymemory. The one or more dedicated processors may take the form of asingle core processor, multi-core processor (e.g., a dual coreprocessor, triple core processor, quad core processor, etc.),microprocessor, etc.

Any foregoing references to currency or funds are intended to includefiat currencies, non-fiat currencies (e.g., precious metals), andmath-based currencies (often referred to as cryptocurrencies). Examplesof math-based currencies include Bitcoin, Litecoin, Dogecoin, and thelike.

It should be noted that although the diagrams herein may show a specificorder and composition of method steps, it is understood that the orderof these steps may differ from what is depicted. For example, two ormore steps may be performed concurrently or with partial concurrence.Also, some method steps that are performed as discrete steps may becombined, steps being performed as a combined step may be separated intodiscrete steps, the sequence of certain processes may be reversed orotherwise varied, and the nature or number of discrete processes may bealtered or varied. The order or sequence of any element or apparatus maybe varied or substituted according to alternative embodiments.Accordingly, all such modifications are intended to be included withinthe scope of the present disclosure as defined in the appended claims.

The foregoing description of embodiments has been presented for purposesof illustration and description. It is not intended to be exhaustive orto limit the disclosure to the precise form disclosed, and modificationsand variations are possible in light of the above teachings or may beacquired from this disclosure. The embodiments were chosen and describedin order to explain the principals of the disclosure and its practicalapplication to enable one skilled in the art to utilize the variousembodiments and with various modifications as are suited to theparticular use contemplated. Other substitutions, modifications, changesand omissions may be made in the design, operating conditions andarrangement of the embodiments without departing from the scope of thepresent disclosure as expressed in the appended claims.

What is claimed is:
 1. A computer-implemented method performed by aglobal transaction processing system, the method comprising: based onprior interactions with an originator, determining a plurality ofpersonal identifying information (PII) items related to the originator;generating an originator profile, the originator profile comprising theplurality of PII items related to the originator; generating anddisplaying, via an originator computing device, an electronic formstructured to allow the originator to designate a subset of theplurality of PII items as automatically accessible by a transactioncorrection circuit to repair, without requesting originator approval,future transactions requested by the originator; based on an originatorinput received from the originator computing device, storing the subsetof the plurality of PII items in the originator profile; receiving afirst batch comprising a plurality of transaction requests from theoriginator, each transaction request comprising transactional dataincluding one or more of originator account information, originatoridentification information, a transaction amount, a transactionrecipient, and transaction recipient account information; for at leastone of the plurality of transaction requests: validating thetransactional data to determine one or more parameters associated withthe requested transaction, wherein the one or more parameters includeone or more of a transaction type, a recipient identity, and a recipientlocation, and wherein the one or more parameters is indicative of atleast one transaction defect; dynamically generating a transactioninformation request form, the transaction information request formincluding one or more requests for specific transactional data from theoriginator based on the one or more parameters associated with therequested transaction; receiving, via the transaction informationrequest form, the requested specific transactional data from theoriginator; determining that the transaction request is automaticallyrepairable based on required data being accessible via the subset of theplurality of PII items from the originator profile; automaticallyrepairing the transaction request using the subset of the plurality ofPII items from the originator profile; generating a data packetcontaining the transactional data and the requested specifictransactional data, wherein the data packet is structured to be readableby a receiving financial institution associated with the transactionrecipient; transmitting the data packet containing the transactionaldata and the requested specific transactional data to the receivingfinancial institution associated with the transaction recipient; andgenerating a score for the plurality of transactions, the score based onthe at least one transaction defect for each transaction; and based onthe score, limiting a size of a second batch for future transactionsassociated with the originator.
 2. The method of claim 1, furthercomprising: validating the transaction request to determine if thetransaction request is valid; when the transaction request is determinedto be valid, then: processing the transaction request, comprisinggenerating one or more data messages containing the transactional dataand the requested specific transactional data, the one or more datamessages configured to be readable by the receiving financialinstitution associated with the transaction recipient; when thetransaction request is determined to be invalid, then: determining ifthe transaction request is automatically repairable based on thetransaction request being determined to be invalid; automaticallyrepairing the transaction request based on the invalid transactionrequest being determined to be able to be automatically repaired; andgenerating an error report based on the invalid transaction requestbeing determined to be unable to be automatically repaired.
 3. Themethod of claim 2, wherein the error report comprises one or more of alist of missing transactional data and incorrect transactional data,wherein the missing transactional data and the incorrect transactionaldata are determined to be the cause of the transaction request beinginvalid.
 4. The method of claim 3, wherein the error report is anelectronically generated report having one or more originatorconfigurable inputs associated with at least one of the missingtransactional data and the incorrect transactional data, the one or moreinputs configured to allow the originator to modify the missingtransactional data and the incorrect transactional data to manuallyrepair the transaction request.
 5. The method of claim 4, furthercomprising receiving the manually repaired transaction request; andprocessing the repaired transactional request.
 6. The method of claim 1,wherein the requested specific transactional data comprises at least oneof originator identity information, transaction specific information,and recipient specific information requirements.
 7. The method of claim6, wherein the recipient specific information includes recipient countryspecific information.
 8. A system for processing global transactions,the system comprising: an originating financial institution computingsystem associated with an originating financial institution configuredto: based on prior interactions with an originator, determine aplurality of personal identifying information (PII) items related to theoriginator; generate an originator profile, the originator profilecomprising the plurality of PII items related to the originator;generate and display an electronic form structured to allow theoriginator to designate a subset of the plurality of PII items asautomatically accessible by a transaction correction circuit to repair,without requesting originator approval, future transactions requested bythe originator; based on an originator input received from theoriginator computing device, store the subset of the plurality of PIIitems in the originator profile; receive a first batch comprising aplurality of global transaction requests from a user device, each globaltransaction request comprising transactional data including one or moreof originator account information, originator identificationinformation, a transaction amount, a transaction recipient, andtransaction recipient account information; for at least one of theplurality of global transaction requests: validate the transactionaldata to determine one or more parameters associated with the globaltransaction request, wherein the one or more parameters include one ormore of a transaction type, a recipient identity, and a recipientlocation, and wherein the one or more parameters is indicative of atleast on transaction defect; dynamically generate a transactioninformation request form, the transaction information request formcomprising input fields generated based on one or more requests forspecific transactional data from the originator, the one or morerequests corresponding to the one or more parameters; receive, via thetransaction information request form, the requested specifictransactional data from the originator; determine that the transactionrequest is automatically repairable based on required data beingaccessible via the subset of the plurality of PII items from theoriginator profile; automatically repair the transaction request usingthe subset of the plurality of PII items from the originator profile;generate a data packet containing the transactional data and therequested specific transactional data, wherein the data packet isstructured to be readable by a receiving financial institutionassociated with the transaction recipient; transmit the data packetcontaining the transactional data and the requested specifictransactional data to the receiving financial institution associatedwith the transaction recipient; and generate a score for the pluralityof transactions, the score based on the at least one transaction defectfor each transaction; and based on the score, limit a size of a secondbatch for future transactions associated with the originator.
 9. Thesystem of claim 8, wherein the originating financial institutioncomputing system is further configured to: validate the transactionrequest to determine if the transaction request is valid; when thetransaction request is determined to be valid, then: process thetransaction request, comprising generating one or more data messagescontaining the transactional data and the requested specifictransactional data, the one or more data messages configured to bereadable by the receiving financial institution associated with thetransaction recipient; when the transaction request is determined to beinvalid, then: determine if the global transaction request isautomatically repairable based on the transaction request beingdetermine to be invalid; automatically repair the global transactionrequest based on the invalid transaction request being determined to beable to be automatically repairable; and generate an error report basedon the invalid global transaction request being determined to be unableto be dynamically repaired, wherein the generated error report istransmitted to the originator.
 10. The system of claim 9, wherein theerror report comprises one or more of a list of missing transactionaldata and incorrect transactional data, the missing transactional dataand the incorrect transactional data determined to be the cause of thetransaction requested being invalid.
 11. The system of claim 10, whereinthe error report is an electronically generated report having one ormore inputs associated with one or more of the missing transactionaldata and the incorrect transactional data, the one or more inputsconfigured to allow the originator to modify the missing transactionaldata and the incorrect transactional data to manually repair thetransaction request.
 12. The system of claim 11, wherein the originatingfinancial institution computing system is further configured to receivethe manually repaired transaction request; and process the repairedtransactional request.
 13. The system of claim 9, wherein theoriginating financial institution computing system is further configuredto automatically repair the invalid global transaction request byaccessing the originator profile, and modify the global transactionrequest with additional information required to repair the globaltransaction request, wherein the additional information is stored in theoriginator profile.
 14. The system of claim 8, wherein the requestedspecific transactional data comprises at least one of originatoridentity information, transaction specific information, and recipientspecific information requirements.
 15. The system of claim 14, whereinthe recipient specific information includes recipient country specificinformation.
 16. The system of claim 8, wherein the originatingfinancial institution computing system is further configured to transmitthe transaction information form to the user device; and receiverequested specific transactional data from the user device.
 17. A globaltransaction processing system, the system comprising: an originatingfinancial institution computing system, the originating financialinstitution computing system configured to: based on prior interactionswith an originator, determine a plurality of personal identifyinginformation (PII) items related to the originator; generate anoriginator profile, the originator profile comprising the plurality ofPII items related to the originator; generate and display, via anoriginator computing device, an electronic form structured to allow theoriginator to designate a subset of the plurality of PII items asautomatically accessible by a transaction correction circuit to repair,without requesting originator approval, future transactions requested bythe originator; based on an originator input received from theoriginator computing device, store the subset of the plurality of PIIitems in the originator profile; receive a first batch comprising aplurality of global transaction request from a user device, each globaltransaction request comprising transactional data including one or moreof originator account information, originator identificationinformation, a transaction amount, a transaction recipient, andtransaction recipient account information; for at least one of theplurality of global transaction requests: validate the transactionaldata to determine one or more parameters associated with the globaltransaction request, wherein the one or more parameters is indicative ofat least one transaction defect; dynamically generate a transactioninformation request form, the transaction information request formcomprising input fields generated based on one or more requests forspecific transactional data from the originator, the one or morerequests corresponding to the one or more parameters; receive, via thetransaction information request form, the requested specifictransactional data from the originator; determine that the transactionrequest is automatically repairable based on required data beingaccessible via the subset of the plurality of PII items from theoriginator profile; automatically repair the transaction request usingthe subset of the plurality of PII items from the originator profile;generate a data packet containing the transactional data and therequested specific transactional data, wherein the data packet isstructured to be readable by a receiving financial institutionassociated with the transaction recipient; transmit the data packetcontaining the transactional data and the requested specifictransactional data to the receiving financial institution associatedwith the transaction recipient; and generate a score for the pluralityof transactions, the score based on the at least one transaction defectfor each transaction; and based on the score, limit a size of a secondbatch for future transactions associated with the originator; validatethe transaction request to determine if the global transaction requestis valid; in response to the global transaction request being determinedto be a valid transaction request: process the transaction request,comprising generating one or more data messages containing thetransactional data and the requested specific transactional data, theone or more data messages configured to be readable by the receivingfinancial institution associated with the transaction recipient;transmit the processed global transactional request to a recipientfinancial institution computing circuit.
 18. The system of claim 17,comprising: in response to the global transaction request beingdetermined to be an invalid transaction request: determine if the globaltransaction request is automatically repairable; automatically repairthe global transaction request based on the invalid global transactionrequest being determined to be able to be automatically repairable; andgenerate an error report based on the invalid global transaction requestbeing determined to be unable to be dynamically repaired, wherein thegenerated error report is transmitted to the originator and wherein theerror report comprises one or more of a list of missing transactionaldata and incorrect transactional data, the missing transactional dataand the incorrect transactional data determined to be the cause of thetransaction requested being invalid.
 19. The system of claim 18, whereinthe error report is an electronically generated report having one ormore user configurable inputs associated with one or more of the missingtransactional data and the incorrect transactional data, the one or moreinputs configured to allow the originator to input the missingtransactional data and the incorrect transactional data to manuallyrepair the transaction request.
 20. The system of claim 19, wherein theoriginating financial institution computing system is further configuredto receive the manually repaired transaction request; and process therepaired transactional request.
 21. The system of claim 17, wherein theoriginating financial institution computing system is further configuredto automatically repair the invalid global transaction request byaccessing an originator profile, and modifying the global transactionrequest with additional information required to repair the globaltransaction request, wherein the additional information is stored in theoriginator profile.
 22. The system of claim 17, wherein the requestedspecific transactional data comprises at least one of originatoridentity information, transaction specific information, and recipientspecific information requirements.
 23. The system of claim 22, whereinthe recipient specific information includes recipient country specificinformation.
 24. The system of claim 17, wherein the originatingfinancial institution computing system is further configured to transmitthe transaction information form to the user device; and receive therequested specific transactional data from the user device.